在管理 Grafana 時,各種不同的 Dashboard、Data Source、權限、Organization 等都需要依照使用場景設定。當數量較少時,還可以依靠手動操作或前面提到的 Provisioning 來進行配置,但隨著使用者增加,各種設定的數量可能會急速上升,這時候就需要自動化設定的方式。
IaC (Infrastructure as Code) 是目前常用於管理服務、機器設定的一種方式,透過定義好的設定檔和 API 來建立服務或機器。常見的 IaC 工具包括 AWS 的 CDK、支援各種服務的 Terraform,以及管理機器設定常用的 Ansible 和 Chef。透過 IaC,可以確保重建相同環境,並且能動態建立資源,減少大量人工操作。
各種 IaC 工具和 Grafana 的互動都是透過 Grafana API 進行。在前面的範例中,我們有使用 curl 更新 Plugin 設定,這使用的就是 Grafana API。如果找不到適合需求的 IaC 工具,也可以自訂資料結構,再透過 Grafana API 來建立資源。例如 Grafana Backup Tool 就是使用 Grafana API 開發的自訂工具。
使用 API 時的認證有兩種方式:
在早期版本中還有 API Key 的認證方式,但現在推薦使用 Service Account。Service Account 可以在 Administration > Users and access 的 Service accounts 頁籤進行設定。
管理 Service Account 的頁面
每個 Service Account 可以發行多個 Token
完整的 API 清單除了官方文件外,也可以在 Grafana 的 /swagger
用 Swagger UI 檢視與操作。以下是一些常用的 API:
Grafana 的 Swagger UI
目前主流的 IaC 工具是由 HashiCorp 開發的 Terraform,透過程式碼可以建立各種服務,例如 K8s 中的 Pod、GCP 上的 Compute Engine、AWS 上的 EC2、Grafana 中的 Dashboard 等等。
HashiCorp 成立於 2012 年,最初的主打產品是從 2010 年開始開發的 Vagrant,旨在幫助開發人員快速、重複搭建相同的虛擬機環境。然而,隨著 2013 年 Docker 的發布,容器技術以更輕量的方式解決了環境配置的問題,取代了 Vagrant 的部分功能。雖然 Vagrant 因此黯然失色,但 HashiCorp 的技術實力使公司得以繼續發展,並在 2014 年推出了 Terraform,主打透過相同的 IaC 語法來管理不同雲端服務供應商的資源配置。
除了 Terraform,HashiCorp 還開發了其他知名工具,包括管理機密資料的 Vault、微服務架構中常用於服務發現的 Consul,以及類似 Kubernetes 的服務編排工具 Nomad。經過多年的努力,HashiCorp 於 2021 年成功在納斯達克上市,目前市值達 69 億美金。
Terraform 定義了 HCL 格式的語言,安裝對應服務的 Provider,例如 Grafana Provider 後,Terraform 可以自動化地操作 Grafana 的資源,實現自動化的 Infrastructure 配置與管理。
Infrastructure as Code 透過 Terraform 的 Plan 與 Apply 建立出各種服務的 Infrastructure,圖片來源:Terraform
Terraform 的安裝與使用可以參考官方網站的 Tutorial,如果對雲端服務不熟悉,可以選擇用 Terraform 建立 Docker Infrastructure 的版本快速入門。以下是使用 Terraform 操作 Grafana Resource 的簡單範例:
使用前需要先設定 Grafana Provider 並指定版本,並執行 terraform init
下載 Grafana Provider 與初始化 Terraform
terraform {
required_providers {
grafana = {
source = "grafana/grafana"
version = "3.9.0"
}
}
}
初始化 Terraform
設定 Grafana Provider,連結到 Grafana 服務,並設定認證方式
provider "grafana" {
url = "http://localhost:3000"
auth = "admin:admin"
}
3.使用 Terraform 語法定義各種 Grafana 資源,例如 Data Source、Folder、Dashboard 等。
resource "grafana_data_source" "prometheus" {
name = "prometheus"
type = "prometheus"
url = "http://prometheus:9090"
}
resource "grafana_folder" "my_folder" {
title = "My Folder"
uid = "my-folder-uid"
}
resource "grafana_dashboard" "my_dashboard" {
folder = grafana_folder.my_folder.uid
config_json = jsonencode({
"title" : "My Dashboard",
"uid" : "my-dashboard-uid"
})
}
執行 terraform apply
來套用設定並建立資源
執行 Terraform Apply,會顯示將異動的資源,並詢問是否確認
透過 Terraform 建立 Grafana 的 Folder 與 Dashboard,可以看到 Folder 的 URL 是使用指定的 UID 建立,而不是平常看到的亂數 ID
透過 Terraform 及 HCL 語法,可以批量建立各種 Grafana 資源,如 User、Folder、Dashboard、Alert 等,詳細範例可以參考本篇 Lab。不過,Terraform 在管理資源時,會將資源的狀態記錄在 .tfstate
檔案中,例如 Dashboard 的 JSON 配置。因此,當 Dashboard 的數量增加時,.tfstate
檔案的大小會急速攀升,這可能導致一些 Terraform 的異常行為或 Bug。
因此,當需要建立和管理大量 Dashboard 時,建議透過 Grafana API 來自行管理這類資源,只讓 Terraform 管理其他不會產生大量 JSON 資料的資源,避免 .tfstate
檔案過大所帶來的問題。
範例程式碼:https://github.com/blueswen/grafana-zero-to-hero/tree/main/07-management/03-iac
此 Lab 會建立
啟動所有服務
docker-compose up -d
安裝 Terraform CLI,進入 tf
目錄執行以下指令
# 下載 Grafana Provider 與 Terraform 初始化
terraform init
# Apply main.tf 中預先定義好的各種 Grafana 資源
terraform apply
登入 Grafana,驗證 tf/main.tf
中的 User、Folder、Dashboard、Alert 是否建立完成,並測試 Grafana API
admin/admin
關閉所有服務
docker-compose down
因此,當需要建立和管理大量 Dashboard 時,建議透過 Grafana API 來自行管理這類資源,只讓 Terraform 管理其他不會產生大量 JSON 資料的資源,避免 .tfstate 檔案過大所帶來的問題。
這段我真有共鳴。只是我還得爭取把 Grafana 這些拿回來我來管理先。我確實是習慣用 Grafana API 去新增刪除修改那些 provisioning,Terraform 只用來弄 Grafana 佈署的infra。
前公司當時選用 TF 管的原因是我們有用 TF 的 GitOps,大量的 User 權限跟 Orgnization 更新靠已有的自動化觸發帶起會比較簡單。最後有做到管理數百個 Resource,但在沒有把 Dashboard 移走前真的莫名其妙就會卡爛 Orz。